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1 

2 FIELD OF THE INVENTION 
3 

4 The present invention relates generally to server-agent environments, and 

5 more particularly to a method, a computer program product and a system for 

6 providing a switch user functionality in such an environment. 
7 

8 BACKGROUND OF THE INVENTION 
9 

10 Nowadays, as information systems become ubiquitous, and companies and 

11 organizations of all sectors become dependent on their computing resources, the 

12 requirement for the availability of the hardware components and software 

13 components (applications) of an IT network and of services based on it, 

14 {hereinafter all three are generally referred to as "objects") is increasing while 

15 the complexity of IT networks is growing. 

16 There are network management systems available which enable the 

17 availability and performance of objects within an IT network to be monitored and 

18 managed. For example, Hewlett-Packard offers such network monitoring and 

19 managing tool, which is a server-based, under the name "OpenView". The 

20 product is available for Windows and Unix operating systems. It comprises a 

21 management server, a user interface to operate the server and several "agents" 

22 for different operating-system platforms. An agent is a program or process 

23 which runs on a managed node. A personal computer, network node {in the 

24 narrow sense) or any system with a CPU is called a node. A managed node is a 

25 node which is monitored and/or managed by the management system. 

26 in order to allow the users of such a system to react to network problems, 

27 the agents implement a feature which enables software tools or applications to 

28 be started remotely. For example, if the operator of the system detects a 

29 possible problem on the monitored node, he can, via the management server and 
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1 using the user interface, initiate the start of a software tool on the monitored 

2 node which carries out diagnosis, recovery, repair and/or reconfiguration 

3 actions. 

4 Often, such a tool must be started using a different user account than the 

5 account of the operator. To achieve this, the agent has a built-in "switch user" 

6 functionality which allows the operator to change his account to the user 

7 account which is needed. To use this functionality on Windows NT systems, the 

8 agent calls a Windows NT application programming interface (API) in a particular 

9 way which is not transparent for normal users, e.g. by including a certain code 

10 which is generated by the agent software independent and is independent from 

11 the account to which the switch user is to be performed. The call will be 

12 forwarded to the Windows NT domain controller. A sub-authentication 

13 component (a dynamic link library (DLL) component), which extends the 

14 standard Windows NT user name and password authentication component on 

15 the domain controller, will receive that call and verify that the call has been 

16 performed in the correct way, e.g. by checking the code word (the standard 

17 Windows NT authentication component is, for example, described in Microsoft 

18 Windows 2000 Security Technical Reference, Redmond, 2000, pages 22-23 and 

19 154-155). If the check reveals that the call has been made correctly, it will allow 

20 the agent to perform the switch user to the requested account. The password of 

21 the account is not needed by the agent or the domain controller to perform the 

22 user switch. 
23 

24 SUMMARY OF THE INVENTION 

25 

26 The invention provides a method for providing a switch user functionality in 

27 a server-agent environment in an information technological (IT) network. At least 

28 one agent runs on a node of the IT network. The method comprises the 

29 following steps: generating a switch user (SU) certificate using public-key 
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1 cryptography upon receiving a request to switch from a user account presently 

2 used on the node to another user account; sending the SU certificate to the 

3 agent; checking the correctness of the SU certificate; performing the requested 

4 switch to the user account provided that the SU certificate is correct. 

5 According to another aspect, the invention provides a computer program 

6 product including program code for providing a switch user functionality in a 

7 server-agent environment in an information technological (IT) network, in which 

8 at least one agent runs on a node of the IT network. Said program code is for: 

9 generating a switch user (SU) certificate using public-key cryptography upon 

10 receiving a request to switch from a user account presently used on the node to 

11 another user account; sending the SU certificate to the agent; checking the 

12 correctness of the SU certificate; performing the requested switch to the user 

13 account provided that the SU certificate is correct. 

14 According to still another aspect, the invention is directed to a system for 

15 managing objects in an information technological (IT) network having a network 

16 management server and at least one management agent which runs on a 

17 managed node of the IT network. The system provides a switch user 

18 functionality. It comprises: an SU certificate generation component which uses 

19 public-key cryptography; an SU certificate sending component which sends the 

20 certificate to the agent; an SU certificate checking component; a user account 

21 switching component performing the requested switch provided that the SU 

22 certificate is correct. 

23 Other features are inherent in the system, computer program product and 

24 method disclosed or will become apparent to those skilled in the art from the 

25 following detailed description of embodiments and its accompanying drawings. 
26 

27 DESCRIPTION OF THE DRAWINGS 
28 

29 In the accompanying drawings: 
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1 Fig. 1 shows a high-level architecture diagram of an object managing 

2 system which provides a switch user functionality; 

3 Fig. 2 illustrates the generation and checking of an SU certificate 

4 according to a first embodiment; 

5 Fig. 3 illustrates the generation and checking of an SU certificate 

6 according to a second embodiment; 

7 Fig. 4 is a flow chart of a switch user certificate method using the 

8 generation and checking method of fig. 3. 
9 

10 DESCRIPTION OF THE PREFERRED EMBODIMENTS 
11 

12 Fig. 1 shows a high-level architecture diagram of a preferred embodiment. 

13 Before proceeding further with the description, however, a few items of the 

14 preferred embodiments will be discussed. 

15 In the preferred embodiments, a switch user functionality is provided in a 



16 server-agent environment in an IT network, such as a computer network or a 

17 telecommunication network. A node is a network object such as a PC, network 

18 node (in the narrow sense) or any system with a CPU. An agent is a program or 

19 process running remotely on a node. For example, an agent may be able to 

20 respond to requests from the server relating to the node or an application 

21 residing on it, perform operations and/or send notifications to the server relating 

22 to the node or the application. 

23 In the preferred embodiments, the server-agent environment is a network 

24 management environment which enables monitoring and management of nodes 

25 of the IT network, which are called "managed nodes". The object to be managed 

26 and monitored may be the managed node, an application (or part of an 

27 application) running on it or a hardware resource needed by the application 

28 (such as a storage disk). The monitoring may comprise passive monitoring (e.g. 

29 collecting error messages produced by the objects) or active monitoring (e.g. by 
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1 periodically sending a request to the object and checking whether it responds 

2 and, if applicable, analyzing the contents of the response). Management tasks 

3 may be, for example, diagnosis tasks, error correcting or fixing tasks, setting 

4 tasks or other network services. 

5 In the preferred embodiments, the server of the server-agent environment is 

6 a management server which controls, administers, records, analyses and/or 

7 displays the management activities and events. The agents are management 

8 agents which respond to monitoring or management requests, perform the 

9 actual monitoring or management operations and/or send event notifications. 

10 It has been recognized by the inventor of the present invention that, in the 

11 prior art mentioned at the outset, the agent software is in a relatively insecure 

12 environment since it is distributed over several or all managed nodes in a 

13 network domain (which can involve a whole network). Therefore, an agent could 

14 be target of "reverse engineering". It cannot be excluded that a malicious user 

15 could intercept a switch user call and find out how the agent is able to perform 

16 the switch user and to simulate the behavior with a self-written program. 

17 In order to exclude such possible attacks, in the preferred embodiments a 

18 switch user (SU) certificate is generated when a switch user request is received, 

19 using public-key cryptography. 

20 In the preferred embodiments, the SU certificate is generated by the 

21 management server, which sends it to the agent. The agent, in turn, forwards 

22 the received SU certificate to a domain controller which carries out the check of 

23 the correctness of the SU certificate and allows the agent to perform the 

24 requested switch user. The management server and domain controllers are 

25 normally in a secure environment and can be seen as save. 

26 In the preferred embodiments, the SU certificate is generated with a digital 

27 signature public-key algorithm, such as RSA or DSA. Digital signatures and 

28 public-key algorithms are, for example, described in B. Schneier: "Applied 

29 Cryptography, 2 nd edition, 1996, pages 34-41, 461-474 and 483-494. 
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1 In the preferred embodiments, a private and public key pair is available 

2 before the SU certificate is generated. For example, the key pair can be 

3 generated during the set-up of the management system. A renewal of the key 

4 pair can be performed manually or automatically from time to time. Recent 

5 operating systems support key generation; for example, an RSA key can be 

6 generated using the Windows NT Crypto API. 

7 In the preferred embodiments, the public key is made public for 

8 "everybody" (i.e. every node and process) within the network or a domain of the 

9 network in which the check of the correctness of the SU certificate is 

10 performed. The publication of the public key can be realized by storing the public 

11 key such that it can be accessed from all the nodes in the network or domain 

12 but cannot be modified by them; only the component which generates the key 

13 pair (e.g. the management server) can modify this information. For example, the 

14 Windows 2000 Active Directory already provides this infrastructure so that the 

15 above-described public key publication can easily be implemented in Windows 

16 2000 domains using the Active Directory (see Windows 2000 Security Technical 

17 Reference, pages 89-151). 

18 The generation of the SU certificate comprises signing an SU document 

19 with the private key. The check of the SU certificate comprises verifying the 

20 signature with the public key. There are many public-key digital signature 

21 algorithms with different implementations (see Schneier, pages 39 and 461- 

22 502). In the most common algorithm, RSA, the signing process is called 

23 encrypting with a private key and the verification process is called decrypting 

24 with a public-key. The verification comprises checking the authenticity and 

25 integrity of the transmitted SU certificate. In other words, it is verified that the 

26 SU certificate originates from the management server and that it has not been 

27 modified in transit. 

28 Apart from choosing a particular public-key algorithm, there are different 

29 possible ways to actually generate a signature. When, for example, RSA is used, 
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1 the plaintext SU document (or that part of it which has to be secured) is 

2 encrypted with the public key, and the resulting ciphertext represents the 

3 signature. In order to verify the signature, it is decrypted with the public key. 

4 For the verification, it is sufficient that the resulting decrypting text is 

5 meaningful, since it is a feature of the used strong encryption algorithms that a 

6 decryption with a wrong public key or any modification of the signature would 

7 result in a completely different plaintext with generally no meaning. It is likewise 

8 possible to explicitly check whether the result of the decryption is identical with 

9 the original plaintext SU document, which, for example, can be transmitted 

10 together with the signature and form part of the SU certificate. 

11 Since the signing process using the whole (plain) data is generally time 

12 consuming, by preference another possibility is chosen. A relatively unique 

13 representation (also called a "fingerprint" or "message digest") of the data (i.e. 

14 the SU document) is first generated using a process in which the data is 

15 "condensed" or "hashed", for example by means of a message digest function 

16 (e.g. a one-way hash function) into a value of relatively small length, thereby 

17 fixing its contents, and the signing process is performed on the fingerprint, 

18 resulting in an equivalent effective authentication. Therefore, the term digital 

19 signature herein refers to the digital signature of either the plain data element(s) 

20 or of any representation (function) thereof. According to this second possibility, 

21 the transmitted SU certificate is composed of the original SU document in 

22 plaintext and, in addition, the fingerprint of this document, encrypted with the 

23 private key. To verify an SU certificate, the plaintext part of the certificate is 

24 condensed by means of the same message digest function (e.g. the one-way 

25 hash function) and the resulting message digest (hash) value is compared with 

26 the fingerprint decrypted with the public key. If these values are equal, the 

27 authenticity and integrity of the SU certificate is verified. Since the plaintext is 

28 generally bigger than the message digest, the message digest does not uniquely 

29 specify the plaintext - it is possible for many plaintexts to have the same 
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1 message digest. However, the message digest has the following characteristics 

2 which makes it useful: i) A message digest is one-way, in the sense that, given 

3 a specific message digest, it is computationally unfeasible to find a plaintext 

4 with that message digest. Thus, the correspondence between a given message 

5 digest and a given plaintext can be verified, but the plaintext cannot be 

6 recovered from the message digest, ii) It is computationally unfeasible to find 

7 two messages with the same message digest. Thus, in practical terms, if a 

8 message digest is verified for a given message, it can be assumed that it was 

9 generated from that message. As a result of these two properties, the message 

10 digest can be relied upon as a concise summary of the plaintext, and it can be 

11 substituted for the plaintext in the digital signature algorithm. Suitable message 

12 digest functions are, for example, MD5 and MD4 (see Schneier, pages 429- 

13 459). 

14 In the preferred embodiments, the SU certificate comprises the account 

15 name to which the account is to be switched and an identification of the node 

16 for which the switch is to be performed. The account name and the 

17 identification are secured by the signature. In the checking step it is verified that 

18 the node identification actually corresponds to the node to which the switch 

19 user request is directed. This ensures that a certificate may not be used by an 

20 attacker for another node. 

21 Preferably, the SU certificate contains no password specific for the account 

22 to which the switch is to be performed. This is because a password- 

23 identification system would require reasonable administrative effort because all 

24 password changes in the network would have to be followed by all network 

25 nodes. In addition, if the password were transmitted with the SU request, an 

26 attacker might be able to catch and decrypt it and use it for malicious purposes. 

27 The password-less switch user functionality of the preferred embodiments 

28 requires little administrative effort and is secure due to the use of the described 

29 switch user certificates. 
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1 In order to avoid what is called replay attacks, the SU certificate should 

2 also preferably comprise a time stamp and/or another certificate identification 

3 stamp. For example, the time stamp indicates the point of time of the 

4 certificate's generation. When the certificate is checked, it is then also verified 

5 that the certificate is not outdated and/or has not been used before by means of 

6 the time stamp or the certificate identification stamp. For example, if the 

7 "lifetime" of a certificate is defined to be five minutes, the certificate older than 

8 this lifetime would be rejected in the check. A certificate which is younger than 

9 the lifetime will pass this check, however, an additional check is performed as to 

10 whether the certificate has already been used by a different request. To this 

11 end, the component which is responsible for the check stores data (for example, 

12 the certificate identification stamp) of all certificates from the last five minutes. 

13 By comparing the present certificate data with all stored ones, it can find out 

14 that a certificate has already been used, and will then deny the switch user 

15 request. If the present request passes all the checks successfully, the certificate 

16 checking component will store the present certificate's data and will remove all 

17 stored certificate data which is older than the lifetime. Then it will allow that the 

18 switch user is performed. 

19 The preferred embodiments of the computer program product comprise 

20 digital program code which, for example, is stored on a computer-readable data 

21 carrier or is in the form of signals transmitted over a computer network. The 

22 preferred embodiments of the program code are written in an object-oriented 

23 programming language (e.g. Java or C+ +). The program code can be loaded (if 

24 needed, after compilation) and executed in a computer or in networked 

25 computers, e.g. a management server network with managed nodes. 

26 Returning now to Fig. 1, it shows a high level architecture diagram of a 

27 preferred embodiment of an object management system 1 which provides a 

28 switch user (SU) functionality. The system 1 is part of a network 2 which 

29 comprises a domain controller 3 and nodes 4, one of which is shown in Fig. 1 . A 
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1 domain constitutes an administrative and security boundary within a network. A 

2 domain controller provides domain-related administrative and security services to 

3 the network nodes and users. For example, it stores domain-wide directory data 

4 (such as the system security policy) and manages user domain interactions, 

5 including user-logon, authentication and directory searches (see Microsoft 

6 Windows 2000 Security, pages 5 and 95). 

7 The node 4 is monitored and managed by the object management system 

8 1, and is thus called a "managed node". An application 5 which is monitored by 

9 the management system 1 runs on the managed node 4. The monitored 

10 application 5 can be part of a complex application (for example, an SAP 

11 application) which may be distributed over several nodes. An agent 6 monitors 

12 the application 5. The agent 6 is a program running on a remote device (here the 

13 node 4) that responds to monitoring or management requests from a 

14 management server 7, performs monitoring and management operations 

15 regarding the monitored application 5 and the managed node 4, and/or sends 

16 event notification to the management server 7. In other preferred embodiments, 

17 the agent runs on a remote or external node which is different from the node 

18 which hosts the monitored application. If they are several applications to be 

19 monitored on one managed node, they will be preferably monitored by one and 

20 the same agent. Although there is normally one agent per managed node, in 

21 other embodiments one agent can manage several nodes. The agent 6 is 

22 configured by a set of specifications and rules, called policy for each application 

23 5 to be monitored. A policy tells the agent what to look for and what to do 

24 when an event occurs. For example, according to a particular policy an agent 

25 filters events and generates messages which inform the management server 7 

26 about the occurrence of certain events and/or the status and performance of the 

27 monitored application 5. The agent 6 also implements a feature to start tools or 

28 applications on the managed node 4 from the management server 7. These may 

29 be, for example, diagnosis tasks, error correcting or fixing tasks or setting tasks. 
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1 The management server 7 provides centralized management services, 

2 processes and/or a management user interface 8 to the management operator 

3 and other users. In particular, the management server 7 collects events and 

4 performance data from the agent 6, processes them and roots the results to a 

5 monitoring console (for example, the user interface 8). The management server 

6 7 also centrally deploys deployment packages, agents and policies, as directed 

7 by the user, and stores definitions and other key parameters. The remote 

8 management tools and applications mentioned above are also started by a user 

9 via the user interface 8 and the management server 7. 

10 During the set-up of the operating system or the management system, a 

11 private and public key pair is generated by the management server 7 using the 

12 Windows NT Crypto API. The management server keeps the private key secret 

13 and publishes the public key using the domain controller's Windows Active 

14 Directory, which is designated as public key publication component 9 in Fig. 1. 

15 If the management system operator wants to start a tool on the managed node 

16 4 which requires a switch to another account he is currently using, he initiates 

17 the call to the corresponding tool and the request to switch to the other 

18 account, without providing the password of the account, via the user interface 

19 8. When the management server 7 gets the request, it generates an SU 

20 certificate by means of a certificate generation component 10, using the private 

21 key. The SU certificate 1 1 is sent by means of a sending component 1 2 to the 

22 managed node 4 together with a usual call to start the tool under the requested 

23 account. The agent 6 receives the call and forwards the certificate to the 

24 domain controller 3 by calling the Windows NT API. The domain controller 3 

25 comprises a DLL component which is designated as the certificate checking 

26 component 13 in Fig. 1. It is specifically adapted to the management server 

27 system 1 in order to allow a switch to another user account without a 

28 password. The DLL component 13 checks the certificate 1 1 using the public key 

29 of the management server 7 which is published by the public key publication 
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1 component 9. If the check reveals that the SU request is acceptable, the DLL 

2 component 13 authorizes the switch user by returning an SU token 14 to the 

3 agent 6. In turn, an account switching component 15 of the agent 6 performs 

4 the switch to the requested other user account, and the agent 6 performs the 

5 tool, according to the request sent by the management server 7. 

6 The generation and checking of an SU certificate according to a first 

7 embodiment is illustrated in Fig. 2. At first, the plaintext SU document 21 is 

8 generated which contains switch user identification data. In the shown 

9 embodiment, it contains five such data: A certificate identifier, the name of the 

10 management server, the name of the managed node on which the switch user is 

11 to be performed, the name of the account to which the switch user is to be 

12 performed, and a time stamp. The SU document 21 is then encrypted with the 

13 management server's private key 22. The resulting ciphertext 1 1 ' of the SU 

14 document 21 is a what is called a digital signature of the SU document 21 and 

15 can be used as the certificate 11 in Fig. 1 . The certificate 11' is then transmitted 

16 to the node 4 on which the switch user is to be performed and is forwarded to 

17 the DLL component 13 of the domain controller 3. The DLL component 13 

18 decrypts the certificate 11' using the public key 23, and thus obtains a 

19 decrypted SU certificate 24. If the SU certificate 11' has not been modified 

20 during transmission and has been decrypted with the correct public key (i. e. the 

21 management server's public key), the decrypted SU certificate 24 is identical 

22 with the original plaintext SU document 21. The subsequent step of checking is 

23 carried out using the decrypted SU certificate 24. In particular, it is checked 

24 whether the contents of the decrypted SU certificate 24 is meaningful (for 

25 example, if it contains the correct name of the management server). If this is the 

26 case, the authenticity and integrity of the SU certificate 11' is proven. 

27 Alternatively, it can be checked whether the decrypted SU certificate 24 is 

28 identical with the plaintext SU document 21 (which may be transmitted together 

29 with the SU certificate 11') in order to verify authenticity and integrity. 
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1 Furthermore, it is checked whether the name of the node indicated in the 

2 decrypted SU certificate 24 corresponds to the node 4 for which the switch user 

3 is requested. Further, it is checked whether the certificate is still within its 

4 lifetime, i. e. whether the time indicated in the time stamp of the decrypted SU 

5 certificate 24 does not indicate a time which lies more than the predetermined 

6 lifetime (e.g. 5 min) in the past. Finally, if the certificate is still within its lifetime, 

7 it is checked whether the certificate has been used before, for example by 

8 comparing the certificate identifier of the decrypted SU certificate 24 with stored 

9 identifiers of those SU certificates which have been processed in the past within 

10 the certificate's lifetime (e.g. within the last 5 min}. The certificate identifier is 

11 optional: In other embodiments, there is no certificate identifier, and another 

12 data (for example the time stamp) is used for the comparison. If all these checks 

13 reveal that the certificate is authentic, has not been modified, corresponds to the 

14 correct node, is not outdated and has not been used before, the requested 

15 switch user is accepted, and, therefore, initiated. 

16 Fig. 3 illustrates the generation and checking of an SU certificate according 

17 to a second embodiment. As with the first embodiment, the first step is the 

18 generation of the plaintext SU document 21. It contains the same switch user 

19 identification data as the SU document 21 described in connection with Fig. 2. 

20 Different from the embodiment of Fig. 2, a message digest function MD is 

21 applied to the SU document 21, resulting in a fingerprint 25 of the SU document 

22 21, which has a reduced length (for example 128 bits). Then, instead of the SU 

23 document 21, only its fingerprint 25 is encrypted with the private key 22. The 

24 encrypted fingerprint constitutes a digital signature 26 of the SU document 21 

25 according to the second embodiment. The signature 26 is then combined with 

26 the plaintext SU document 21. Their combination forms the certificate 11" 

27 according to the second embodiment, which can be used as the certificate 1 1 in 

28 Fig. 1. The certificate 11" is then transmitted to the node 4 and forwarded to 

29 the DLL component 13 of the domain controller 3, as with Fig. 2. The DLL 
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1 component 13 decrypts the signature 26 with the public key 23, which reveals 

2 the decrypted signature 27. If the correct public key has been used and the 

3 signature 26 has not been modified, the decryption of the signature 26 reveals 

4 the original fingerprint 25. Further, the DLL component 13 generates a message 

5 digest 28 of the plaintext SU document part of the certificate 11". The 

6 decrypted signature 27 and the message digest 28 of the plaintext part of the 

7 certificate 11" are then compared, if they are identical, the authenticity and 

8 integrity of the certificate 11" is verified since any modification of the plaintext 

9 part of the certificate 11" would result in a different message digest 28 and a 

10 decryption of the signature 26 with a wrong public key or any modification of 

11 the signature would have the consequence that the decrypted signature 27 is 

12 different from the signature 26 and, thus, from the message digest 28. The 

13 other checks correspond to the ones described in connection with Fig. 2 and 

14 need not be repeated here. If the results of all checks are satisfactory, the 

15 requested switch user is initiated. 

16 The purpose of the inclusion of the data "name of the server" in the SU 

17 certificates 11' and 11" of Figs. 2 and 3 is to enable the agents to handle SU 

18 requests from different management servers, each having its own private and 

19 public key pair. Such an environment is also called a Manager of Manager 

20 environment. Since the name of the "certificate holder" is known, the DLL 

21 component 13 is able to check the certificate with the correct key and, thus, to 

22 verify that the request actually comes from a valid management server. It should 

23 be noted that in the embodiment of Fig. 2 the certificate 1 V has to contain the 

24 name of the server (also) in plaintext in order to identify the correct public key 

25 needed for the decryption of the encrypted part of the certificate 11'. In 

26 embodiments with only one management server, the data "name of the server" 

27 can be omitted. 

28 Fig. 4 shows a flow chart of a switch user method using the certificate 

29 generation and checking method of Fig. 3. In step S1 a private and public key 
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1 pair is generated. In step S2 the private key is secretly stored in the 

2 management server's secure environment, and the public key is published. The 

3 steps S1 and S2 are carried out during system set-up and, optionally, also 

4 periodically after the system set-up. Step S3 (and the following steps) are 

5 performed when the operator requests a tool and a switch user on a managed 

6 node. In step S4, the management server generates an SU document and signs 

7 it with the management server's private key. The result is an SU certificate. In 

8 step S5 the management server sends the SU certificate to the managed node 

9 together with a call to perform the tool under the requested account. In step S6 

10 the agent receives a call with the SU certificate and forwards the SU certificate 

11 to the domain controller. In step S7 the domain controller verifies the signature 

12 with the public key of the management server. In particular, it verifies that the 

13 SU document received by the agent is authentic and has not been modified. In 

14 addition, it is ascertained whether the certificate has actually been directed to 

15 the correct node, whether it is still within its lifetime and whether it has not yet 

16 been used before. If the answers to all these questions are positive, the domain 

17 controller returns in step S8 an SU token to the managed node. In step S9, the 

18 managed node performs the switch user and starts the tool, as was requested in 

19 step S3. If the answer to any of the questions in step S7 is negative, the switch 

20 user request is denied in step S10. After steps S9 and S10, the method is 

21 prepared to perform another switch user sequence with steps S3 to S9 or S3 to 

22 S7 and S10. 

23 Thus, a general purpose of the preferred embodiments is to provide an 

24 improved method, computer program product and system for providing a switch 

25 user functionality not requiring a password in an IT-network. In particular, the 

26 preferred embodiments prevent: (i) an attacker who "catches" a switch user call 

27 from gaining relevant information from it, since no password is provided with the 

28 call; (ii) an attacker from being able to reuse the call later, because of the 

29 provided time stamp; (iii) an attacker from being able to reuse the call on a 
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1 different managed node, since the certificate contains the name of the managed 

2 node; (iv) an attacker from generating his own call, since the certificate is 

3 digitally signed by the management server and this cannot be done by somebody 

4 else. Thus, the preferred embodiments provide security improvements in a 

5 switch user functionality without a password. 

6 All publications and existing systems mentioned in this specification are 

7 herein incorporated by reference. 

8 Although certain systems, methods and products constructed in 

9 accordance with the teachings of the invention have been described herein, the 

10 scope of coverage of this patent is not limited thereto. On the contrary, this 

11 patent covers all embodiments of the teachings of the invention fairly falling 

12 within the scope of the appended claims either literally or under the doctrine of 

13 equivalents. 



